In order for diverse applications to communicate with one another and share data, standards (uniform conventions for data storage and communication) had to be established. Standards allow businesses to use applications in a heterogeneous operating environment, which run on top of infrastructure from multiple vendors. Standards also promote portability, making it possible for an organization to migrate from one system to another. Indirectly, standards also make it easier and cheaper to implement a complex system, because they impose a proven framework for solving problems by breaking them into discrete parts.
In 1989, a diverse group of vendors and users who believed in the benefits of object-oriented development formed an industry coalition. This group's goal was the development of a consensual standard for work with objects. This coalition, the Object Management Group (OMG), is now the world's largest software consortium, with more than 800 corporate members. CORBA, the Common Object Request Broker Architecture, is the OMG's distributed, object-oriented application standard [CORBRA2.3.1] which is incorporated herein by reference. The architecture described how object-oriented programs should communicate with one another in a distributed computing environment.
At the heart of the CORBA specification is the Object Request Broker (ORB). The ORB is the software entity that manages the interactions between objects (called CORBA objects) on the network. For example, if an application wishes to invoke a function on a CORBA object on another computer, it is the ORB that locates the object and guarantees that the function will be correctly invoked on the target object. An ORB might be implemented as a software library, as operating system kernel routines, as an executable program, or as some combination of the three. From the users' point of view, it is irrelevant how the ORB is implemented; all that matters is the functionality that the ORB provides.
The CORBA specification mandates the location transparency of objects. This means that the developer need only be concerned with which objects to contact and how to invoke function calls, not where those objects are physically located on the network. When a client wishes to communicate with the CORBA server, it sends that request to the ORB, which locates (or creates) the requested object and initiates communication between the two. The ORB frees the client application from having to know whether the objects it requires reside on the same computer or are located on remote computers somewhere on the network. The client application only needs to know the objects' names and understand the details of how to use each object through a call to its interface. The ORB takes care of the details of locating the object, routing the request, and returning the result. The location transparency property of the CORBA specification greatly facilitates the development of distributed applications.
The programming language in which objects are implemented is not important. It makes no difference if a front-end client program is written in Java or Smalltalk, while the server application is written in C or C++. The CORBA architecture guarantees that any CORBA client can communicate with any CORBA server. This flexibility is achieved by converting the programming language-dependent data types to language-independent CORBA data types. The CORBA data types are then transferred through the underlying communication medium. The process of converting language-dependent data types to CORBA data types is called ‘marshalling’. The reverse process, converting CORBA data types to language-dependent data types, is called ‘demarshalling’. Marshalling/demarshalling is performed on the arguments of CORBA method invocations.
The Object Management Group's Interface Definition Language (IDL) is a language that defines interfaces for object-based systems. The language-independent IDL files define the operations that an object is prepared to perform, the input and output parameters it requires, and any exceptions that may be generated along the way. IDL files can be thought of as a contract that a CORBA server writes for potential clients of the object. Such clients must use the same interface definition to build and dispatch invocations that the CORBA server uses to receive and respond. The client and the server are then connected via at least three pieces of software: an IDL stub on the client, one or more ORBs, and a corresponding IDL skeleton in the object's implementation. IDL is responsible for CORBA's language flexibility. It is kind of “middle-ware” that allows a program written in C++ to use objects written in Smalltalk, for example, and vice-versa. IDL can even be used to create object-based servers in languages like C that are not object-oriented. Indeed, with IDL, an entire program running on one computer can be viewed as a single object by a client running on another. A word processor, a spreadsheet or a CAD system can have an interface written in IDL to offer object-based services to clients running on other machines. Thus, IDL and CORBA are ideally suited for object-based interfaces to transaction processing systems.
The Object Transaction Service (OTS) is the Object Management Group's formal specification [OTS97], which is incorporated herein by reference, describing how programs should communicate with transaction processing servers in an object-oriented way. It defines a list of services that can be provided to aid in online transaction processing by defining how atomic transactions can be distributed over multiple objects and multiple ORBs. It is part of the CORBA services.
The word transaction has a very broad scope but generally can refer to an automated operation in which multiple steps must occur successfully in order for the entire operation to be considered successful. If a failure occurs at any step in the operation then any parameters that were modified by previous steps are typically rolled back to the status they held before the entire operation began. If all steps are completed successfully then the transaction can be said to be committed and no rollbacks are permitted. Within CORBA, the OTS specification includes interfaces that implement functions such as rollback and commit that are necessary to implement distributed transaction processing. An ORB-based transaction can include multiple local database transactions controlled through OTS. It can include a single database transaction on a local or remote server. If the transaction is entirely local to the client that initiates it, then the ORB can be bypassed and the transaction can be controlled locally. Further, the OTS offers the capability of supporting recoverable nested transactions, in either a homogeneous or heterogeneous environment, that fully support Atomicity, Consistency, Isolation, and Durability (ACID), and two-phase commit protocols.
CORBA provides a mechanism that allows an application programmer to execute some custom code on either the client or server side prior to the execution of the implemented CORBA method code. This concept is called intercepting a method invocation and the custom code that gets executed is known as an interceptor. Interceptors are an optional extension to the ORB. An interceptor is interposed in either the invocation and/or response paths between a client and a targeted object and is responsible for the execution of one or more ORB services. Typically, the ORB will invoke an interceptor upon receiving a particular request for services from a targeted object. The interceptor will then perform one or more actions, including invoking other objects. In this manner, interceptors provide a way to add portable ORB services to a CORBA compliant object system.
When a client calls a method to begin a transaction, a transaction context is created and passed to the server by means of an interceptor. The transaction context describes such things as which clients, servers, and databases are involved in the transaction and which operations are to be performed. The transaction context also typically has a transaction identification number that can be referred to as the XID. As the transaction context is passed among various clients and serves in the course of a transaction, the OTS uses the XID to keep track of the status of the transaction.
There are traditionally two ways to indicate that an operation is a transaction. One is to inherit all methods from an interface provided by the OTS called Transactional Object. The OTS knows that any method inherited from Transactional Object is a transaction. The drawback of this technique is that all methods inherited from Transactional Object will be treated as transactions regardless of whether a user actually wants them to be considered transactions. The other way of designating an operation as a transaction is to add an extra parameter to the transactional methods. This allows a user to choose which methods are transactional but has the drawback that a change in any method requires a change in the interface. Every client using the interface must then be recompiled.
A system called Encore has been developed to overcome these drawbacks by eliminating the need for extra parameters or for inheritance from another interface. With Encore, a file called a deployment descriptor is used to designate which methods are and are not transactional. All method calls are intercepted and looked up in the deployment descriptor. If the deployment descriptor indicates that a method is transactional then the appropriate transaction context information is passed with the method in an interceptor. The deployment descriptor can be changed at any time without the need for recompiling an application.